There is an ever increasing demand for mobility in communications systems. However, this demand must be met in a manner which provides for the secure transfer of data between communicating parties. A concept known as Virtual Private Network (VPN) has recently been introduced with the aim of satisfying, by a combination of encryption and secure access, this demand. A VPN may involve one or more corporate Local Area Networks (LANs) or Intranets, as well as users coupled to “foreign” LANs, the Internet, wireless mobile networks, etc. An Internet Engineering Task Force (IETF) standard known as IPsec has been defined and provides for the creation of a secure connection between parties in a VPN over IPv6. In the IPsec model, the end points of the secure connection are identified by their IP addresses. Although this may be satisfactory for users having a fixed connection, it does present problems for the mobile user (such as a user who connects to the VPN via a wireless terminal) who wishes to roam between different access networks. The main problem is that the IP address allocated to the roaming mobile user is likely to change dynamically as the user moves between access networks. In the event of an IP address change, it is difficult to reuse the pre-existing security associations (of IPsec) and, in the worst case scenario, the communicating parties need to make a re-authentication of one another and establish new security associations on the basis of the new IP address(es). VPNs provide security gateways or firewalls which control access to a VPN from users outside the VPN. Whilst a mobile user is located within the VPN, the preparations for future lightweight and secure remote access are made. A Security Association (as disclosed in RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP), November 1998) is negotiated between the mobile user and the security gateway. The ISAKMP security association provides protection for messaging in accordance with RFC 2409, The Internet Key Exchange (IKE), November 1998. One or more pairs of security associations are established for the purpose of protecting actual user data traffic. Further security associations may be necessary in order to ensure secure communication with the mobile user when outside the VPN.
Security associations generally have a limited lifetime so as to prevent unauthorised access by deciphering each security association. When a security association reaches the end of its defined lifetime, it is replaced by another previously negotiated security association between the mobile user and the security gateway.
The security gateway comprises a central processing unit (CPU) which contains a Security Association Database (SAD) comprising all of the currently non-expired security associations relevant for communication with the VPN. Access to the VPN is controlled on the basis of the security associations in the SAD. In the event of a power failure or other failure within the security gateway, all security associations can be lost. For example, there may be of the order of 300 such security associations and these will need to be renegotiated when the security gateway is operational again so as to re-establish secure communication. The Internet Engineering task Force (IETF) provides some specifications for restoring operation following such a failure and loss of the SAD but these techniques require a substantial amount of time before secure communication can be restored.